• Allow arm64 builds to consume amd64-only vendor stages by pinning platform in Dockerfile.
• Update Tekton pipelines to Buildah 0.10 and permit cross-platform base images.
• Switch SAST tasks to Trusted Artifacts (oci-ta) and wire SOURCE/CACHI2 artifacts.

graph TD
  P(["Tekton pipeline"]) --> GC["git-clone-oci-ta"] --> PD["prefetch-dependencies-oci-ta"] --> B["buildah-remote-oci-ta (0.10)"] --> IDX["build-image-index"] --> SAST["SAST *-oci-ta tasks"]
  B --> DF["Dockerfile"] --> V{{"Vendor images (amd64-only)"}}
  PD -. "SOURCE_ARTIFACT/CACHI2" .-> SAST
  subgraph Legend
    direction LR
    _p(["Pipeline"]) ~~~ _t["Task"] ~~~ _e{{"External/Registry"}} ~~~ _f["Config/File"]
  end

Loading

The following are alternative approaches to this PR:

1. Publish multi-arch vendor images

• ➕ Avoids cross-platform pulls/emulation edge cases
• ➕ Keeps Dockerfile architecture-neutral
• ➕ Reduces reliance on ALLOW_CROSS_PLATFORM_IMAGES escapes
• ➖ Requires upstream/vendor changes and release coordination
• ➖ Longer lead time than a pipeline/Dockerfile fix

2. Fetch vendor CLIs from official release artifacts

• ➕ Removes dependency on amd64-only container images
• ➕ Often easier to pin checksums/versions per tool
• ➖ More bespoke install logic and verification in Dockerfile
• ➖ May diverge from Red Hat supported distribution of tools

3. Build vendor tooling from source during image build

• ➕ Fully reproducible and architecture-native outputs
• ➕ No dependency on prebuilt vendor images
• ➖ Significantly increases build time/complexity
• ➖ Requires toolchains and extra maintenance

Recommendation: The chosen approach is the fastest, lowest-risk unblock for the Buildah 0.10 bump: force amd64 only where strictly necessary (vendor COPY stages) and explicitly allow cross-platform pulls in the build task. Consider a follow-up to move vendor images to multi-arch to remove the cross-platform escape hatch over time.

Bug fix (1) +5 / -5

DockerfileForce amd64 vendor stages; pin EPEL release; update UBI10 base +5/-5

Force amd64 vendor stages; pin EPEL release; update UBI10 base

• Pins vendor COPY stages (ec-rhel9, cosign-rhel9, rhacs-roxctl-rhel8) to linux/amd64 so arm64 builds can still copy required binaries. Updates the UBI10 base image digest/tag. Pins epel-release to a specific noarch RPM URL to keep EC RPM versioning consistent across architectures.

Dockerfile

Other (2) +62 / -48

release-service-utils-standalone-pull-request.yamlBump task bundles; allow cross-platform builds; move SAST to oci-ta +31/-24

Bump task bundles; allow cross-platform builds; move SAST to oci-ta

• Updates multiple Konflux task bundle digests, including buildah-remote-oci-ta 0.9 → 0.10. Adds ALLOW_CROSS_PLATFORM_IMAGES=true to the build task to tolerate amd64-only base/vendor images on arm64. Switches SAST tasks to *-oci-ta variants and passes SOURCE_ARTIFACT/CACHI2_ARTIFACT from prefetch-dependencies; also removes/empties some workspace wiring for those tasks.

.tekton/release-service-utils-standalone-pull-request.yaml

release-service-utils-standalone-push.yamlAlign push pipeline with cross-platform Buildah 0.10 + oci-ta SAST +31/-24

Align push pipeline with cross-platform Buildah 0.10 + oci-ta SAST

• Mirrors the pull-request pipeline updates: bumps task bundle digests and upgrades buildah-remote-oci-ta to 0.10. Enables ALLOW_CROSS_PLATFORM_IMAGES for the image build. Migrates SAST tasks to *-oci-ta variants and wires SOURCE_ARTIFACT/CACHI2_ARTIFACT inputs, with workspace definitions removed/emptied where no longer needed.

.tekton/release-service-utils-standalone-push.yaml

Description

The Dockerfile now forces the roxctl stage to linux/amd64, but the final image unconditionally
copies /usr/bin/roxctl from that stage. Since the Tekton PipelineRun builds a linux/arm64 image, the
arm64 image will embed an amd64 roxctl binary and roxctl execution will fail on arm64 hosts.

Code

Dockerfile[7]

+FROM --platform=linux/amd64 registry.redhat.io/advanced-cluster-security/rhacs-roxctl-rhel8:4.10.4-1 as roxctl

Relevance

⭐⭐⭐ High

Repo previously fixed wrong-arch binary issues in Dockerfile for multi-arch (cosign) to avoid ARM
exec failures.

PR-#608
PR-#609
PR-#571

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The roxctl stage is explicitly pinned to amd64, and its binary is copied into the final image. The
pipeline builds an arm64 image, so that arm64 image will necessarily include an amd64 roxctl binary.

Dockerfile[7-7]
Dockerfile[78-78]
.tekton/release-service-utils-standalone-pull-request.yaml[119-123]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The final runtime image always copies `roxctl` from an amd64-only stage (`FROM --platform=linux/amd64 ... as roxctl`). This makes the `linux/arm64` image contain an amd64 `roxctl` binary.

## Issue Context
The pipeline builds multi-arch images (`linux/x86_64` and `linux/arm64`). With the new amd64-pinned vendor stage, the copied executable cannot match arm64.

## Fix approach (one of)
1. **Fetch roxctl for the target arch** during the final stage (similar to how `cosign3` is downloaded), using the same arch mapping already present in the Dockerfile.
2. **Stop shipping roxctl** in the runtime image (if not required), or split it into an amd64-only image.
3. If a multi-arch source exists, **switch the roxctl stage to a multi-arch image** (remove `--platform=linux/amd64`) and rely on correct platform resolution.

## Fix Focus Areas
- Dockerfile[7-7]
- Dockerfile[78-78]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools